如何优化HTTPS实现访问加速？
一
前言
HTTPS（超文本传输安全协议）是HTTP协议的安全版本，它使用SSL/TLS协议进行加密和身份验证。
通常，SSL/TLS协议需要完成四次握手，然后开始发送Application Data，整个过程如下图所示：
相比于HTTP协议，HTTPS在SSL/TLS握手过程中增加了“加密套件协商”、“密钥协商”、“证书有效性校验”、“证书身份认证”等过程，这些确保了数据传输的安全性，但同时也都影响着应用程序的访问速度。
在对功耗、带宽、性能、响应时间等要求苛刻的场景中，如何通过HTTPS的优化实现访问加速？便成了经常遇到的问题。
2月14日，“vivo千镜”公众号发布的《HTTPS会话恢复技术解析》一文中，介绍了通过会话恢复机制（Session ID和Session Ticket）实现HTTPS场景下访问速度的提升。在本文中，我们继续介绍其他HTTPS优化方案。
HTTPS优化方案
HTTPS访问速度优化的本质是对TLS握手过程的优化，尽可能使用更少的交互完成整个流程。下面详细介绍两种通过减少通信RT（Round-Trip）实现HTTPS访问加速的方案：TLS False Start方案（适用于TLS1.2及之前的版本）、TLS1.3方案。
2.1 TLS False Start方案
False Start，字面意思是：抢跑。那么，关键是怎么让TLS抢跑？
通常，在TLS握手过程中，Application Data是在TLS握手完毕后，再使用key加密传输。试想一下，如果我们不再等待TLS握手结束，而是在key生成之后直接加密Application Data，并将其发送到服务端，是不是同样能够在满足安全的前提下，完成整个数据传输过程呢？答案是肯定的，这也正是Google提出来的TLS False Start。
TLS False Start的握手流程：在TLS协商阶段，客户端发送Change Cipher Spec和 Finished后，不等待服务端的确认，立即发送加密的应用数据。也就是说，在不需要修改TLS协议情况下，False Start相当于客户端提前发送加密后的应用数据给服务端，等到服务端生成key时，再执行对请求包解密和响应包加密的操作。
从上图可以明显看出，TLS False Start以更少的交互完成了TLS握手。
通过Wireshark抓包，可以看到在启用False Start场景中TLS的握手过程，如下图所示：
上图中的56号数据包，Client先发送了Application Data，而Server发送的Change Cipher Spec则在其之后的58号数据包中才出现。实际交互过程比常规TLS握手少了一个RTT（Round-Trip Time，往返时延），当然也就提升了应用的访问速度。
直观的说，TLS False Start不会修改TLS握手协议，而只是修改发送Application Data的协议时序。一旦Client发送了 Client Key Exchange记录，则代表Client就已经知道加密密钥并可以开始传输应用程序数据；握手的其余部分用于确认没有人篡改握手记录，并且可以并行完成。
一般来讲，采用TLS False Start可以使HTTPS服务的第一个请求延迟减少25%，如果进一步结合TCP Fast Open，可以将时间减少50%。
①启用TLS False Start，浏览器需要支持NPN/ALPN。目前主流浏览器都是默认支持的，如Microsoft Edge、Chrome、Firefox和Safari等；
②服务端需配置支持前向安全Forward Secrecy。因为False Start在尚未完成握手时就发送了应用数据，使用支持前向安全（Forward Secrecy）的加密算法可以提高安全性。
2.2 TLS 1.3方案
在2018年8月份，IETF正式发布TLS1.3协议的最终版本（RFC8446），该协议在性能、隐私和安全性上都有重大改进。相比于TLS1.2，TLS1.3大大提升了HTTPS的连接速度。
可以看出TLS1.3舍弃了RSA和Diffie-Hellman密钥协商的过程，然后基于ECDH算法优化了整个过程，使得TLS1.3只需要1个RTT就可以完成握手。
实际上，TLS1.3遵循“少即是多”的思想，在TLS1.2的基础上做了很多改变，但TLS1.3的主要变化有以下几点：
对握手状态机进行了调整，删除了Change Cipher Spec之类的多余消息；
对所支持的对称加密算法列表进行了更新，删除了SHA-1等不安全的加密算法；
所有基于public-key的密钥交换机制都提供Forward Secrecy，删除了不支持Forward Secrecy的静态RSA和Diffie-Hellman密码套件；
对Server Hello后的握手消息加密传输；同时，通过引入Encrypted Extensions，保证了之前在Server Hello中以明文形式传输的扩展的机密性；
在TLS1.3中，椭圆曲线算法属于基本规范，且包含了新的签名算法，如 EdDSA；
添加了0-RTT模式，以节省会话恢复时建立连接的时间。
通过以上改进，大大提升了TLS的握手速度，既保证了传输的安全性，又缩短了响应时间。
TLS1.3会话恢复过程
即便TLS 1.2采用了Session ID或Session Ticket机制恢复会话，也仍然需要1个RTT，而TLS 1.3的会话恢复过程实现了0个RTT就能完成，如下图所示：
TLS1.3建立首次连接时，使client和server获得同一个预共享密钥PSK。那么在会话恢复时，TLS1.3允许Client发送的第一个消息中的early data中携带数据，并使用上述PSK加密early data并认证Server。通过这种方式，实现0-RTT传输数据的目的。
目前，Chrome、Firefox、Safari等主流浏览器已经支持TLS1.3，但多数浏览器默认不启用TLS1.3，需要用户主动修改配置。如：Firefox 97.0.1默认开启TLS1.3，而Chrome 98的默认选项则是Default，需要手动改为Enabled；
另一方面，由于互联网复杂的生态系统，一些用于监控或者拦截的middlebox，也会导致TLS1.3连接的失败。所以，在决定采用TLS1.3之前，需要谨慎检查网络环境、浏览器、服务器是否都已支持。
小结
不管是Session ID、Session Ticket会话恢复机制，还是TLS False Start机制，再或者是TLS1.3，其实都是在满足已有的安全要求情况下，对握手的流程进行优化，减少RTT次数，最终实现HTTPS访问加速。
除了上述减少握手RTT次数的思路外，还可以针对TCP握手过程优化、证书校验过程优化，如TCP Fast Open、OCSP Stapling等也是常用于提升HTTPS访问速度的措施。
参考文章
[1]RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
https://datatracker.ietf.org/doc/html/rfc5280
[2] RFC8446: The Transport Layer Security (TLS) Protocol Version 1.3
https://datatracker.ietf.org/doc/html/rfc8446
[3] Transport Layer Security (TLS) False Start draft-bmoeller-tls-falsestart-00
https://datatracker.ietf.org/doc/html/draft-bmoeller-tls-falsestart-00
[4] 使用 HTTPS 确保网站安全
https://developers.google.com/search/docs/advanced/security/https
[5] Transport Layer Security (TLS)
https://hpbn.co/transport-layer-security-tls/
[6] Why TLS 1.3 isn't in browsers yet
https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/
[7] A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)
https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
[8] TLS 1.3 - Enhanced Performance, Hardened Security
https://www.cloudflare.com/learning-resources/tls-1-3/
[9] RFC7413：TCP Fast Open
https://www.rfc-editor.org/rfc/rfc7413
[10] RFC6961：The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
https://datatracker.ietf.org/doc/html/rfc6961
精彩文章推荐